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(54) Support for trusted software distribution 

(57) A form of authentication is provided wherein a 
trusted third party signs a certificate to identify the 
author of a program and to secure its integrity. The pro- 
gram code is encapsulated or otherwise associated with 
the certificate and an access control list (ACL). The 
access control list describes the permissions and 
resources required by the code. An enforcement mech- 
anism which allocates system permissions and 
resources in accordance with the ACL. In a preferred 
embodiment, a code production system communicates 
with a certification agency, which is a trusted third party. 
The certification agency issues a certificate for the code 
and a certificate for the access list of that code. Once 
the certificate is issued it is not possible for any party to 
modify the code or access list without invalidating the 
certificate. The code and its ACL, along with their certif- 
icates are stored on a server. A client downloading the 
code or access list can verify the integrity of the 
code/access list and the system can enforce the access 
list such that the permissions and resources are not 
exceeded. 
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Description 

The present invention relates generally to delivery of software through distribution systems such as networks. 

Software distribution is a major industry currently. Software is today distributed over diskettes, CD ROMs and 
5 increasingly, over networks. In addition to simply downloading code from remote sites over the Internet, today clients 
can download and run applets from servers, a paradigm proposed in the Java programming language or in other lan- 
guages such as Telescript. 

A significant concern with code obtained from elsewhere is that of security. For example, in the Unix operating sys- 
tem, the code will run in the client's shell with all the client's privileges, including access to all his files, as well as pos- 

10 sibly send mail, attempt illegal break ins etc. Java attempts to solve this problem for applets by running applets in a very 
restrictive environment. As a result, the usefulness and functionality of Java applets is limited. Java applications on the 
other hand rely on the security provided by the operating system and do not come with any degree with authentication. 
They thus pose the same security problems as any other code. 

A form of authentication is proposed in Trusted Distribution of Software Over the Internet", A.D. Rubin, Internet 

is Society Symposium on Network and Distributed Security, 1995. Here a trusted third party signs a certificate to identify 
the author of a program and to secure its integrity. While this allows a client to verify the authenticity of the code, it does 
not specify a flexible set of permissions associated with the code nor does it provide an automated method for the client 
to enforce these permissions. 

In a preferred embodiment, a code production system communicates with a certification agency, which is a trusted 

20 third party. The certification agency issues a cerif icate for the code and a certificate for the access list of that code. Once 
the certificate is issued it is not possible for any party to modify the code or access list without invalidating the certificate. 
The code and its ACL, along with their certificates are stored on a server. A client downloading the code or access list 
can verify the integrity of the code/access list and the system can enforce the access list such that the permissions and 
resources are not exceeded. 

25 According to one aspect of the present invention there is provided a method for distributing program code compris- 
ing the steps of providing to a recipient system a trusted third party certification, the trusted third party certification 
including a computer readable description of resources and permissions required for verified non-harmful operation of 
the code. 

According to a second aspect of the present invention there is provided a method for distributing program code 
30 comprising the steps of: 

providing a recipient system with an encrypted trusted third party certification of the program code, the trusted third 
party certification being encapsulated with the program code and including a computer readable description of 
resources and permissions required for verified non-harmful operation of the code; 
35 reading the certification by the recipient system; 

determining the integrity of the certification by the recipient system; and 
only after the integrity has been verified, 

allocating resources and permissions of the recipient system in accordance with user selected options so as not to 
exceed the permissions specified in the certification; and 
40 executing the program code in accordance with the allocating. 

wherein the descriptions of resources required includes data describing both a quantity of each resource to 
be used by the code and a maximum rate of consumption of each resource by the code and wherein the descrip- 
tions of permissions required includes data describing specific facilities of the recipient system to be accessed by 
the code. 

45 

Figure 1 shows a block-diagram view of a code delivery and certification system according the preferred embodi- 
ment of the invention; 

Figure 2 shows how the different parts of the client system operate together to perform the functions described in 
the embodiment; 
so Figure 3 shows the access control list (ACL) ; 

Figure 4 shows the data structures used by the ACL enforcer; 

Figure 5 shows how logical resource permissions are enforced by the ACL enforcer; 

Figure 6 shows how physical resource limits are enforced by the ACL enforcer; 

Figure 7 shows the pseudocode for the integrity verification, execution and enforcement initialization operations of 
55 the client system; 

Figure 8 shows the pseudocode for the ACL manager; and 
Figure 9 shows the pseudocode for the ACL enforcer. 

Figure 1 shows a block-diagram view of a code delivery and certification system according to a preferred embodi- 
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ment of the invention. It includes of one or more code production systems (CPS) 1 0, a certification agency (CA) 1 5, one 
or more servers 20 and one or more client systems 30. The client systems can be coupled to the servers by way of a 
conventional Wide Area Network (WAN) or by way of a Local Area Network (LAN). The CPS has a piece of program 
code (code) 1 40 and an access list (ACL) 1 50 for that code that it wishes to get certified by the certification agency. The 

5 CA provides a public key K that is widely available and known to the client system. In addition the CA has a private key 
P that only it knows. To provide a certificate for the code the CA creates a certificate containing the code name and the 
cryptographic hash of the code and signs it using his private key. The certificate cannot now be changed without inval- 
idating the CA's signature. Similarly the CA creates and signs another certificate for the ACL associated with that code 
(if desired there could be a single certificate for both the code and its access list). In the embodiment of Figure 1, the 

w client systems receive the certificate, the ACL and the code by way of the WAN or LAN. It should be understood, how- 
ever, that the client systems can also or alternatively receive certified code by way of a removable storage media read 
by local importation device such as a floppy or optical disk drive. 

The client system shown in Figure 2 includes a verifier 110, ACL manager 130, executor 170, ACL enforcer 180 
and a client interface 190. The client system also includes a conventional CPU and associated control logic 192, a com- 

75 munication controller/network interface 1 94, a CD-ROM and/or floppy disk subsystem 196 and other resources such as 
network access modules, a display subsystem and various special purpose adapters. Those of skill in the art will rec- 
ognize that the client system includes a number of additional, conventional components which will not be described in 
detail here. 

The ACL manager 1 30 and the ACL enforcer 1 80 are preferably embodied as program code, the operation of which 
20 is described in more detail below. The executer is a conventional part of the client's operating system (not shown) which 
is used to execute the imported code on the client system. The client interface 1 90 can be embodied as a front of screen 
graphical user interface which provides the client communication with the ACL manager (e.g. it enables the client to tell 
the ACL manager 130 to allow or disallow or control program access to specified resource). Tiie verifier 1 10 is prefer- 
ably embodied as program code including a decryption module which is used to verify the authenticity of the imported 
25 code, including the access control list. The verifier also includes a hashing module which checks the integrity of the 
imported code and ACL. 

Upon downloading the code/ACL and its certificate (100), the verifier (110) first checks to see if the CA's signature 
on the certificate is valid (using CA's known public key). The verifier then computes the cryptographic hash of the 
code/ACL and verifies that it matches the value in the certificate. If the signature is not valid or the hash does not match, 

30 the code and ACL are rejected (1 20). If the verification is ok, the ACL manager (1 30) is invoked. The ACL manager dis- 
plays the ACL (described below) to the client via the client interface (190) and ascertains whether the client wishes to 
allow or disallow the individual items in the ACL. The ACL manager stores the code (140) as directed by the client via 
the client interface and stores the ACL (150) together with permission flags (160). 

The resources that can have their access controlled by the ACL enforcer include both logical resources such as f ile- 

35 systems, specific files and system calls, as well as physical resources including such things as the disk space, disk 
access, main memory allocation and access to various system controllers and adapters. For access to logical 
resources (client system facilities), the permission flags 160 indicate whether individual items are allowed or not; for 
access to physical resources, the permission flags can be used to indicate the maximum allowable quantity or rate of 
consumption. 

40 Figure 2 also shows how the different parts of the client system operate together. In a multi-user client system, each 
user may have their own set of permission flags. The ACL may also contain environment variables; changing the envi- 
ronment variables during execution allows individual users to customize the access privileges. The ACL and permission 
flags are stored in a secure area; reading or updating this area is a privilege enforced by the ACL enforcer (180). 

The ACL manager may be invoked at any time by the client to display or change the permissions of an ACL. The 

45 code is run by the executor (1 70). Before allowing access to any resource, the executor invokes the ACL enforcer for 
checking the validity of the access. This is achieved by the executor 170 inserting traps in the code to a verification rou- 
tine that invokes the ACL enforcer. The operation of the ACL enforcer is described in more detail later. 

The system enables the code and its ACL to be downloaded separately or together as needed. For instance, the 
CPS may want to provide the ACL free of charge to all clients but charge for the actual code. 

so Figure 3 shows the access control list. The ACL consists of two parts: the Physical Resources Table (PRT) 200 
containing the physical resources required by the code and the Logical Resources Table (LRT) 250 containing the per- 
missions and logical resources required by the code. 

The PRT 250 contains a row for each resource containing the physical resource name (PRN) 205, the resource 
attribute 210. the maximum consumption rate 215 and the maximum amount 220. The resource attribute 210 is used 

55 when a physical device or resource disk has multiple attributes, such as space and number of 1/Os for storage devices. 
The maximum consumption rate 215 and the maximum amount 220 are the maximum allowable consumption rate and 
maximum allowable consumption of the resource and attribute respectively. 

The LRT 250 contains a row for each call to an external routine required by the code (referred to as a logical 
resource). Each row contains the logical resource name (LRN) 255, and a parameter list 260 that points to a list of 
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parameter entries. Each parameter entry 265 specifies a set of valid parameter ranges; i.e. a set of values for each 
parameter that are valid in combination, together with a field nextPE 280 that points to the next parameter entry. The 
parameter range for each parameter contains two fields - the parameter type 270 and the parameter value 275 that 
specifies the valid range for that parameter. For string parameters, the parameter type 270 is STR and the parameter 

5 value 275 is a list of regular expression that specify valid forms for the string. For integer parameters, the parameter type 
270 is INT and the parm. value 275 is a list of integer ranges. The parm. value 275 may include the names of environ- 
ment variables, in which case the environment variable is assumed to contain a value which is substituted at run time. 

The ACL enforcer in the client ensures that the permissions and resources specified in the ACL for the code are 
provided and no additional permissions/resources are allowed. 

10 The ACL enforcement may be static or dynamic. In static enforcement, the enforcement can be done fully before 
the code is executed and no enforcement is required while the code is running. In dynamic enforcement, the enforce- 
ment must be performed while the code is being executed. If the CA itself verifies the ACL and guarantees that they will 
not be exceeded by the code, then the ACL enforcement function may not be required in the client system. 

Figure 4 shows the data structures used by the ACL enforcer. The Runtime Physical Resources Table (RPRT) 300 

is contains a row for each resource. The resource name 300, resource attribute 310, maximum consumption rate 315 and 
maximum amount 320 are copies of the corresponding fields from the PRT 200. The actual consumption rate 325 and 
the actual use 330 fields are used to keep track of the actual consumption rate and the actual consumption, respec- 
tively, of the code during run time. The Runtime Logical Resource Table (RLRT) 350 contains a row for each required 
logical resource. The RLRT is a copy of the LRT, with an additional flag that indicates for each valid combination of 

20 parameters, whether the combination is allowed by the ACL manager or not. The Logical Resource Name 355 is a copy 
of the corresponding fields of the LRT 250 and the parameter list 360 points to a list of runtime parameter entries (RPE) 
365. The parameter type 370, parameter value 375 values of the runtime parameter entries are copies of the corre- 
sponding fields in the LRT. The nextPE 380 points to the next runtime parameter entry 365 and the allow 385 field may 
be set to YES or NO indicating whether this runtime parameter entry 365 is allowed or not.The ACL enforcer also keeps 

25 track of the code start time 395. 

Figure 5 shows how logical resource permissions are enforced by the ACL enforcer. This path is invoked whenever 
the code makes a call to an external function. In step 410, the ACL enforcer locates the number of parameters, their 
values, and the name of the function being invoked. The exact method for doing this is implementation dependent; for 
example, in Java, these are located on the operand stack. In step 41 5, the ACL enforcer locates the row for this function 

30 in the RLRT 350 and locates the first RPE 365 with allow set to YES. If the function name is not found, or there is no 
such RPE 365, the ACL enforcer proceeds to step 455 where it exits indicating that the call is not allowed. In step 420, 
the ACL enforcer locates the value of the first parameter and makes that the current parameter. In step 425, the ACL 
enforcer checks if the value of the current parameter is allowed by the RPE 365. If the value is allowed, the ACL enforcer 
checks in step 430 if there are more parameters. If there are, in step 435 the ACL enforcer sets the current parameter 

35 to the next parameter and returns to step 425. If no more parameters are found in step 430, the ACL enforcer proceeds 
to step 450 and returns with an indication that the call is allowed. 

If the test for allowability fails in step 425, the ACL enforcer proceeds to step 445 where it checks the RLRT 350 to 
find another RPE 365 with allow 385 set to YES. If there is no such RPE, the ACL enforcer proceeds to step 455 and 
exits indicating that the call is not allowed. If there is such an RPE 365. the ACL enforcer proceeds to step 420. 

40 Figure 6 shows how physical requirements are enforced by the ACL enforcer. The ACL enforcer is invoked in step 
500 before allocating the resource. Two parameters, the amount of the resource requested (REQAMT) and the esti- 
mated time of consumption (COMPT) are provided. For disk I/O, the REQAMT is the amount of disk I/O and the 
COMPT is the estimated time for the I/O to complete. In step 505, the ACL enforcer locates the row in the RPRT 300 
for this resource and checks whether the maximum amount 320 is specified and the actual use 330 plus REQAMT 

45 exceeds the maximum amount 320. If so, it returns a failure in step 527 indicating that the consumption is not allowed. 
If the maximum amount 320 is not exceeded, in step 510 the ACL enforcer computes the projected consumption rate 
of this resource as (Actual use 330 + REQAMT)/(current time - code start time 395 + COMPT) . In step 515. the ACL 
enforcer checks to see if the maximum consumption rate 315 is specified and if the projected consumption rate is 
greater than the maximum consumption rate 315. If the maximum consumption rate 315 is not specified or the projected 

so consumption rate is not greater, the ACL enforcer returns with an indication that the consumption is allowed. If the pro- 
jected consumption rate is greater, the ACL enforcer in step 530 computes the required delay for performing this oper- 
ation as (actual use 300 + REQAMT)/maximum consumption rate 315 -(current time - code start time 395 -COMPT) 
and returns the required delay with an indication that the consumption has to be delayed for the computed delay. 

In step 550. the ACL enforcer is invoked after the consumption of the resource with a parameter specifying the 

55 amount of resource consumed (CONSAMT). The ACL enforcer then updates the actual consumption rate 325 and the 
actual use 330. 

It is also possible for different users to be allocated different resources and permissions in the recipient system for 
the same code. This can be done either at the time the code is installed, by the ACL manager by looking at the privi- 
leges given to the different users and combining that with the resources and permissions allowed to the code. In this 
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case the set of resources and permissions for each user would have to be stored separately. During code execution the 
resources and permissions would be enforced on a per-user basis. Alternatively the resources and permissions can be 
determined during execution of the code by the ACL enforcer by looking at the privileges given to the different users and 
combining that with the resources and permissions allowed to the code. 

5 Figure 7 shows the pseudocode for the integrity verification, execution and enforcement initialization operations of 

the client system. It should be understood that the various tables, lists flags and other data structures described herein 
are instantiated in the memory of the client system (e.g. in volatile random access memory, disk or a combination of 
both). As previously discussed, the ACL enforcer and ACL manager are preferably embodied as program code which 
is linked or incorporated into the operating system of the client system. Figure 8 shows pseudocode for the ACL man- 

10 ager. Figure 9 shows pseudocode for the ACL enforcer. 

Now that the invention has been described by way of the preferred embodiment, various modifications and 
improvements will occur to those of skill in the art. Thus, it should be understood that the preferred embodiment has 
been provided as an example and not as a limitation. 

In summary, there is described a form of authentication is provided wherein a trusted third party signs a certificate 

15 to identify the author of a program and to secure its integrity. The program code is encapsulated or otherwise associated 
with the certificate and an access control list (ACL). The access control list describes the permissions and resources 
required by the code. An enforcement mechanism which allocates system permissions and resources in accordance 
with the ACL. In a preferred embodiment, a code production system communicates with a certification agency, which is 
a trusted third party. The certification agency issues a certificate for the code and a certificate for the access list of that 

20 code. Once the certificate is issued it is not possible for any party to modify the code or access list without invalidating 
the certificate. The code and its ACL, along with their certificates are stored on a server. A client downloading the code 
or access list can verify the integrity of the code/access list and the system can enforce the access list such that the 
permissions and resources are not exceeded. 

25 Claims 

1 . A method for distributing program code comprising the steps of providing to a recipient system a trusted third party 
certification, the trusted third party certification including a computer readable description of resources and permis- 
sions required for verified non-harmful operation of the code. 

30 

2. The method of Claim 1 wherein the proving comprising the step of encapsulating the certification with the program 
code. 

3. The method of Claim 1 or 2 comprising the further steps of reading the certification by the recipient system; and, 
35 allocating resources and permissions of the recipient system so as not to exceed the permissions specified in the 

certification. 

4. The method of Claim 1 , 2 or 3 comprising the further steps of denying or granting the code access and permissions 
to resources of the recipient system in further accordance with user selected options associated with the certifica- 
te tion. 

5. The method of any of Claims 1 to 4 wherein the computer readable description of resources and permissions is 
provided to the recipient system in an encrypted form. 

45 6. The method of any of Claims 1 to 5 wherein the certification further includes encrypted verification data and 
wherein the recipient system decrypts the verification data to verify the integrity of the description of the resources 
and permissions. 

7. The method of any of Claims 1 to 6 wherein the descriptions of resources required includes data describing both a 
so quantity of each resource to be used by the code and a maximum rate of consumption of each resource by the 

code. 

8. The method of any of Claims 1 to 7 wherein the descriptions of permissions required includes data describing spe- 
cific facilities of the recipient system to be accessed by the code. 

55 

9. The method of any of Claims 1 to 8 wherein the third party certification includes a description of the functionality of 
the code as verified by the third party. 

1 0. The method of any of Claims 1 to 9 wherein the program code is an applet downloaded from a server as a program 
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object. 

11. The method of any of Claims 1 to 10 wherein different users are allocated different resources and permissions in 
the recipient system for the same code. 

5 

1 2. The method of Claim 1 1 wherein the set of resources and permissions allowed to different users is determined dur- 
ing installation of the code or during execution of the code. 

13. A method for distributing program code comprising the steps of: 

10 

providing a recipient system with an encrypted trusted third party certification of the program code, the trusted 
third party certification being encapsulated with the program code and including a computer readable descrip- 
tion of resources and permissions required for verified non-harmful operation of the code; 

15 reading the certification by the recipient system; 

determining the integrity of the certification by the recipient system; and 

only after the integrity has been verified; 

20 

allocating resources and permissions of the recipient system in accordance with user selected options so as 
not to exceed the permissions specified in the certification; and 

executing the program code in accordance with the allocating; 
25 wherein the descriptions of resources required includes data describing both a quantity of each 

resource to be used by the code and a maximum rate of consumption of each resource by the code and 
wherein the descriptions of permissions required includes data describing specific facilities of the recipient sys- 
tem to be accessed by the code. 

30 14. A computing system, comprising: 

an importation device for importing programs and data into the computing system; 

an operating system for controlling the operation of the computing system; 

35 

access logic for extracting from the data and associating with a given program a computer readable description 
of resources required for verified non-harmful operation of the code, the access logic further including integrity 
checking logic for generating verification data indicative of the integrity of the computer readable description; 
and 

40 

enforcement logic coupled to the operating system and responsive to the verification data tracking and allocat- 
ing for each of a number of resources, consumption and consumption rate within the recipient system so as not 
to exceed the allocations specified in the description; and 

45 a processor for executing the program code in accordance with the allocating. 

15. The system of Claim 14 further including a data structure stored in a random access memory and coupled to the 
enforcement logic, the data structure including at least a first field for tracking actual resources consumed and a 
second field for tracking rate of consumption of the resources, a third field for storing a limit on resource consump- 

so tion derived from the description and a fourth field for storing limit on the rate of consumption of the resource 
derived from the description. 

16. The system of Claim 15 wherein the access manager includes means for de-encapsulating the description from a 
package including the program code and means for decrypting the description. 

55 

17. The system of Claim 15 further wherein the enforcement logic includes means for denying or granting the code 
access and permissions to resources of the computing system in further accordance with user selected options 
associated with the description. 
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FIG. 3 
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FIG. 5 
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FIG. 6 
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FIG. 7 
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FIG. 9 
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(54) Method for downloading software from server to terminal 



(57) The invention relates to a telephone system 
and a method for downloading software from a server 
(128) to a terminal (100, 102), the method comprising 
the steps of attaching to the software a certificate con- 
firming the authenticity of the software and the loader; 
downloading the software from a source computer (1 34) 
to the server (128); downloading the software from the 



server (128) to the terminal (100, 102). In the method of 
the invention a first electronic signature confirming the 
authenticity of the software is attached to the software 
at the server (128). After the software is downloaded, a 
second electronic signature is generated at the terminal 
from the loaded software and the authenticity of the soft- 
ware is checked by comparing the first electronic signa- 
ture with the second. 
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Description 

FIELD OF THE INVENTION 

[0001] The invention relates to a method for down- 
loading software from a server to a terminal in a tele- 
phone system comprising a plural number of terminals 
and a management system server that monitors and 
controls the operation of the terminals, a terminal of the 
system comprising means for storing one or more soft- 
ware. 

BACKGROUND OF THE INVENTION 

[0002] As radio telephone systems become increas- 
ingly common and their coverage areas grow - the sys- 
tems often replacing those implemented by fixed line tel- 
ephone connections - it has become necessary to de- 
velop telephone networks supporting radio telephone 
systems such as cellular radio systems. Such tele- 
phones are needed, for example, in areas where fixed 
line telephone connections do not exist, or in applica- 
tions in which the terminal is in a place, for example in 
a moving vehicle, where connection to a fixed network 
is not easily available. The present invention can be ap- 
plied particularly to systems implemented by means of 
cellular radio systems. 

[0003] The systems and terminals involved include 
pay phones, so-called WLL (wireless local loop) termi- 
nals, payment terminals at points of sale and smart card 
terminals supporting transfer of money between a card 
and a bank. 

[0004] The functions in current terminals are to a large 
extent implemented by means of various types of soft- 
ware. The terminal comprises a processor and memory 
into which the necessary software is stored. When the 
user selects a function, the software is read from the 
memory and carried out. In the designing of terminals, 
a compromise between the number of functions and the 
available memory capacity has been necessary. Due to 
reasons of cost, the size of the memory in the terminals 
cannot be infinitely increased, therefore the memory lim- 
its the number of the functions. 

[0005] Let us study, by way of example, a pay phone 
system implemented by means of a radio system. The 
system comprises a plural number of pay phones, each 
communicating with base stations over a radio path. For 
the radio path and the base station, the terminals func- 
tioning as pay phones do not deviate in any way from 
conventional subscriber terminals. For collection of pay- 
ments, the pay phones comprise a collection device that 
can typically be a payment card reading device. Numer- 
ous different payment cards are available, such as dif- 
ferent types of credit cards, reloadable payment cards, 
bank cards, etc. In addition, the card types vary accord- 
ing to the card manufacturer and the company offering 
the card, and different facilities can be selected for one 
and the same card. Each card type requires the terminal 



to be provided with software supporting the card, i.e. a 
card application. The card application comprises the 
routines required for the terminal's user interface, for 
controlling the card and for performing a transaction, 

5 such as a payment. 

[0006] To have card applications supporting all card 
types stored into the memory of a terminal reading a 
card would require such a large memory that the termi- 
nal would be expensive. Furthermore, the adding of new 

10 card applications to the terminal would require the soft- 
ware of the entire equipment to be changed at hardware 
maintenance. 

[0007] Problems similar to those relating to pay 
phones also affect other wireless devices in which pay- 
is ment cards are read, such as reloading devices allowing 
electronic money to be loaded from a bank account to 
a payment card. 

[0008] To solve the above problem, it is advantageous 
if software can be downloaded through the network 

20 when necessary, thereby allowing the terminal's mem- 
ory to be optimally utilized. When a card is inserted into 
a terminal which does not have software corresponding 
to the card, the terminal can download the needed soft- 
ware to its memory through the network from a prede- 

25 term in ed server. 

[0009] This method has, however, its shortcomings. 
The use of software downloaded from a network in- 
volves risks that must be taken into account. It is impor- 
tant that the software to be downloaded is flawless and 

30 does not contain software viruses, for example, or other 
harmful elements. It is also important to be able to verify 
that the software is downloaded from the correct server 
and that it is manufactured by the correct software man- 
ufacturer. A defective software can cause malfunction 

35 in the terminal, such as unintended calls and transac- 
tions to wrong addresses. 

BRIEF DESCRIPTION OF THE INVENTION 

40 [0010] An object of the invention is therefore to pro- 
vide a method and an apparatus implementing the 
method so as to allow the above problems to be solved. 
This is achieved with a method for downloading soft- 
ware from a server to a terminal, the method comprising 
45 the steps of attaching to the software a certificate con- 
firming the authenticity of the software manufacturer 
and the loader; downloading the software from a source 
computer to the server; calculating a check sum for the 
software and the certificate; and downloading the soft- 
50 ware from the server to the terminal. The method of the 
invention further comprises the steps of adding the 
check sum confirming the authenticity of the software to 
the software at the server before the software is down- 
loaded to terminals: generating a second check sum at 
55 the terminal from the downloaded software, after the 
software has been downloaded; and checking the au- 
thenticity of the software at the terminal by comparing 
the first check sum with the second. 
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[0011] The invention further relates to a telephone 
system comprising a plural number of terminals and a 
server monitoring and controlling the operation of the 
terminals, the server being arranged to calculate a 
check sum for the software and the certificate attached 
to the software; a terminal of the telephone system com- 
prising means for storing one or more software, and the 
system comprising one or more source computers ar- 
ranged to upload software to the server, the terminals 
being arranged to download the software from the serv- 
er. In the telephone system of the invention the. server 
is arranged to attach to the software a first check sum 
confirming the authenticity of the software before the 
software is downloaded to the terminals, and a terminal 
is arranged to generate a second check sum from the 
downloaded software, after the software has been load- 
ed, and that the terminal is arranged to check the au- 
thenticity of the software by comparing the first check 
sum with the second. 

[0012] The dependent claims relate to preferred em- 
bodiments of the invention. 

[0013] The method and system of the invention pro- 
vide several advantages. With the solution of the inven- 
tion it is easy to ensure that the software is safe and that 
it is uploaded to the server from a safe source computer. 
The invention employs digital signature to ensure the 
authenticity of the software. Corresponding methods 
have earlier been applied only in connection with elec- 
tronic mail transmissions. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0014] In the following the invention will be described 
in greater detail in connection with preferred embodi- 
ments and with reference to the accompanying draw- 
ings, in which 

Figure 1 is a diagram illustrating a structure of a tel- 
ephone system of the invention; 
Figure 2 is a block diagram illustrating a structure 
of a terminal of a system according to the invention; 
Figure 3 is a flowchart illustrating a method of the 
invention; and 

Figure 4 is a flow chart illustrating the downloading 
of software. 

DETAILED DESCRIPTION OF THE INVENTION 

[001 5] In the following the invention will be described, 
by way of example, with reference to a pay phone sys- 
tem implemented by applying a digital GSM mobile 
phone system, the invention not being, however, limited 
to the example. It is apparent that the solution of the 
invention can be modified to apply to telephone systems 
implemented by means of any other technology and 
comprising terminals which include functions operated 
by means of software applications. 
[0016] Figure 1 illustrates a structure of a pay phone 



system implemented in a cellular radio network. The 
system comprises a plural number of pay phones 
100-102, each connected via a radio path 104-106 to 
base stations 108-110. For the radio path or the base 

5 station, terminals operating as pay phones do not differ 
in any way from conventional subscriber terminals. The 
base stations 108-110 are typically connected to base 
station controllers 116-118, each controller controlling a 
plural number of base stations, via transmission lines 

10 112-114 which can be implemented by means of optical 
cables, copper cables or link connections. The base sta- 
tion controllers 1 1 6-1 1 8, in turn, are connected via trans- 
mission lines 120-122 to a mobile services switching 
centre 124 which controls the operation of the base sta- 

'5 tion controllers and transmits calls from the terminals to 
a fixed network or to other parts of the cellular radio sys- 
tem via transmission lines 126. 

[0017] The pay phone system further comprises a 
management system server 128 which controls and 

20 monitors the operation of the pay phones 100-102. In 
the GSM system used as an example, a control equip- 
ment server 1 28 of the pay phone system is connected 
via an X.25 interface 130, for example, to a short mes- 
sage centre 132 which is, in turn, connected to GSM 

25 cellular networks and their mobile switching centres. 
The above description of the cellular radio system thus 
relates to the GSM system, but it is obvious that al- 
though the details of other systems vary from the above 
description, there are no essential structural differenc- 

30 es. It should be noted that also in the GSM system the 
pay phone system can be implemented without the short 
message centre, by connecting the control equipment 
server 128 of the pay phone system to the cellular radio 
system by employing other prior art methods, such as 

35 a modem. 

[0018] The system of the invention further comprises 
a source computer 1 34, such as a computer of the man- 
ufacturer of the software used in the terminals. The 
source computer 1 34 is connected to the server 1 28 via 

40 a telecommunications network 1 36, such as the Internet 
or a private network. Both the server and the source 
computer can be implemented as computer hardware 
having the required telecommunications characteristics 
and the appropriate software. 

45 [0019] Figure 2 illustrates an example of a preferred 
embodiment of a pay phone according to the system of 
the invention. The pay phone of the invention comprises 
a cellular radio transceiver 200 and a control unit 204 
which has a direct connection 202 to the transceiver 200 

50 without a two-wire connection. The terminal of the in- 
vention further comprises a collection means 206 con- 
nected to the control unit 204. Depending on the appli- 
cation, the collection means can accept phone cards, 
credit cards or smart cards as means of payment. The 

55 terminal typically also comprises a dialling means 210 
for dialling the desired telephone number, display unit 
208 and an earpiece 212. The terminal can also com- 
prise means 214 allowing a hands tree facility, the 
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means comprising a speaker 216 and a microphone 
218, and the necessary amplifiers. II desired, some or 
all of the above components can be directly integrated 
into the transceiver 200, or they can be implemented as 
separate means, although structurally possibly within s 
the same casing. 

[0020] The function of the transceiver unit 200 is to 
provide, when necessary, a radio connection to a base 
station to allow a call to be transmitted. The unit 200 
also takes care of all operations (usually carried out by 
a mobile phone) concerning the maintenance of the ra- 
dio path and the call. 

[0021] The function of the control unit 204 is to control 
the pay phone. The control unit typically comprises a 
micro processor, fixed and reprogrammable memory 
circuits, multiplexing means and switches. The control 
unit controls the operations of other units included in the 
equipment, registers placed calls and takes care of deb- 
iting. The operational parameters of the pay phone are 
usually stored in the control unit's memory. Such tele- 
phone-specific parameters include telephone number, 
tariff data relating to the calls to be placed, language 
options on the telephone's display and volume of voice. 
Except for the inventive features described in the 
present application, the operation of the control unit 
does not basically differ from the operation of the control 
units of prior art pay phones. 

[0022] The details of the terminal structure can also 
vary from the above description depending on the pur- 
pose of use of the terminal. For example, if the terminal 
is a payment terminal used at a point of sale, the device 
does not necessarily include audio parts such as a mi- 
crophone or speaker. At its simplest, the terminal com- 
prises a cellular radio transceiver, a control unit and col- 
lection means which can be structurally integrated with 
each other or, alternatively, they may be components 
detachable from one another and temporarily connect- 
ed together for the duration of a call payment or a pur- 
chase transaction, for example. 

[0023] The software needed by the terminal are 
stored into the memory of a control unit 204. The soft- 
ware concerned include software, or card applications, 
needed by various payment card alternatives. A card 
application comprises routines needed for the terminal's 
user interface, for controlling a card and for carrying out 
a card transaction, such as a payment. 
[0024] Let us then study the method of the invention 
with reference to a flow diagram shown in Figure 3. As 
stated above, the system of the invention allows soft- 
ware to be downloaded to terminals, when necessary, 
from the system server. To ensure the authenticity of the 
software it is important that software can only be upload- 
ed to the server from a source the authenticity of which 
has been confirmed. In the solution of the invention, 
each software supplier is therefore provided with a spe- 
cific digital certificate that allows the software supplier., 
or the supplier's computer (hereinafter referred to as the 
source computer) from which the software is uploaded 



to the server, to be identified. The certificate is granted 
by a third party, such as the terminal manufacturer. 
[0025] In step 300 of Figure 3, the software producer 
attaches a digital certificate confirming the authenticity 
of the software to the software to be transferred to a 
server. In step 302 the software is uploaded from the 
software producer's source computer via, for example, 
the Internet or another link to the network server which 
in this example is the server of the pay phone system. 
In a preferred embodiment of the invention, the server 
checks the source computer's certificate in connection 
with the downloading. 

[0026] When software is downloaded to terminals, it 
is also essential that the software is downloaded from 
an official server agreed on in advance and not from a 
disturber that has connected to the network. It is there- 
fore necessary that the origin of the software can be ver- 
ified from the software. For this purpose the software is 
provided with an electronic signature at the server, the 
signature being attached to the software in step 306. In 
the preferred embodiment of the invention, the electron- 
ic signature is generated by calculating a check sum in 
step 304 for the software and the certificate and by at- 
taching the check sum to the software in step 306, pref- 
erably by using encryption, thereby preventing any ex- 
ternal party from corrupting the sum. The check sum it- 
self can be calculated by applying methods known to 
those skilled in the art. One way of implementing the 
encryption is to use a public key and secret key encryp- 
tion method. The electronic signature is attached to the 
software at the server in step 306 by using the server's 
secret key which outsiders do not know. The encrypted 
information can then be decrypted by using a public key 
at the terminal. In the solution of the invention, encryp- 
tion methods known to those skilled in the art can be 
used. 

[0027] In step 308 the terminal downloads the soft- 
ware needed from the server. After the terminal has 
downloaded the software, it checks the authenticity of 
the software in step 310 by calculating, similarly as at 
the server, the check sum of the downloaded software 
and the certificate attached to the software. The terminal 
then decrypts the encrypted electronic signature at- 
tached to the software at the server in step 31 2 by using 
the server's public key. As a result of the decryption, the 
check sum calculated at the server is obtained. The ter- 
minal compares the check sum it has calculated with 
that calculated at the server in step 31 4, the result of the 
comparison allowing the terminal to decide the authen- 
ticity. If the check sums match, the software is authentic 
(step 316), but if the check sums do not match, the 
source of the software is not authentic (step 318) and 
the software cannot be taken into use. 
[0028] Let us then study an example of a situation 
where the above described downloading of the software 
cannot be carried out; this is illustrated in a flow diagram 
of Figure 4. In step 400 the user has inserted a card into 
a card reader 206 of a terminal. In step 402 the terminal 
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checks the different functions of the card, for example, 
any credit card alternatives included. If several options 
are available, the user gets to select the function to be 
used. The routine then proceeds to step 406 to check 
whether an application required by the selected function 
is included in the terminal's memory. The application 
keeps record of the applications available in its memory 
at a particular moment. If the application is in the mem- 
ory, it can be started in step 408. 
[0029] If the application is not in the terminal's mem- 
ory, the routine proceeds to step 410 to check whether 
the application is in the management system's server. 
Information about the applications that can be down- 
loaded from the server can be stored either in the ter- 
minal, or the terminal can request the information from 
the server. If the application cannot be found from the 
management system, the function is rejected in step 41 2 
and the user is asked to give a new one, provided that 
the card contains several functions. 
[0030] If the application is on the management sys- 
tem's server, the terminal asks in step 414 the amount 
of memory required by the application. The terminal 
then checks in step 416 whether the amount of memory 
required by the application is available. If there is not 
enough memory available, an application to be removed 
from the memory is selected and removed in step 418 
so as to release memory for the new application. The 
terminal can let the user select the application to be re- 
moved or, alternatively, the terminal can make the deci- 
sion on the basis of a predetermined criterion. One cri- 
terion is to keep recently used applications and to re- 
move an application that has been unused for the long- 
est. 

[0031] The terminal then informs in step 420 the serv- 
er of a free memory area where the application should 
be placed. For example, the terminal can inform a mem- 
ory area 312, shown in Figure 3, to be available for the 
application. The management system's server down- 
loads in step 422 the application to the memory area 
informed by the terminal. The application is then ready 
to be taken into use in step 424. 
[0032] In another alternative embodiment the man- 
agement system's server does not control the placing 
of the application into the terminal's memory, but only 
transmits the application to the terminal which then plac- 
es the application into its memory. 
[0033] In addition to payment card applications, a 
downloadable software can comprise facilities trans- 
ferred in an electronic form, such as timetable informa- 
tion or tickets. 

[0034] Method steps associated with the terminal of 
the invention can be advantageously implemented by 
software at the terminal's control unit 204. The connec- 
tion to the management system's server required by the 
method can be advantageously provided by means of a 
data call connection. A data call is a call type that is 
available in digital radio networks; it corresponds to a 
modem connection in analog systems. 



[0035] At the management system's server and in the 
software manufacturer's source computer the functions 
of the invention can be advantageously implemented by 
means of software. 
5 [0036] Although the invention is described above with 
reference to an example shown in the attached draw- 
ings, it is apparent that the invention is not restricted to 
it, but can vary in many ways within the inventive idea 
disclosed in the attached claims. 



Claims 

1. A method for downloading software from a server 
is (128) to a terminal (100, 102), the method compris- 
ing the steps of 

attaching to the software a certificate confirm- 
ing the authenticity of the software manufactur- 
20 er and the loader; 

uploading the software from a source computer 
(134) to the server (128); 
calculating a check sum for the software and 
the certificate; and 
2S downloading the software from the server (1 28) 

to the terminal (100, 102), 

characterized in that the method further com- 
prises the steps of 

30 

attaching the check sum confirming the authen- 
ticity of the software to the software at the serv- 
er (128) before the software is downloaded to 
terminals; 

35 generating a second check sum at the terminal 

from the downloaded software, after the soft- 
ware has been downloaded; and 
checking the authenticity of the software at the 
terminal by comparing the first check sum with 
40 the second. 

2. A method according to claim 1 , characterized in 
that the authenticity of the software is always 
checked at the terminal (100, 102) when the soft- 

45 ware is carried out. 

3. A method according to claim 1 , characterized in 
that the method comprises the generating of an 
electronic signature at the server (128) by calculat- 

50 ing for the software and the certificate a common 
check sum which is encrypted by means of a secret 
key of the server. 

4. A method according to claim 3, characterized in 
55 that the encryption of the secret key is decrypted at 

the terminal (100, 102) by means of a public key of 
the server (128). 
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5. A method according to claim 1 , characterized in 
that the terminal (100, 102) detects that a payment 
card is inserted into the terminal's card reader (206) 
and the user has selected an application, and that 
the terminal 

checks whether the software needed for imple- 
menting the application can be found in the ter- 
minal's memory, and 

sends the server (128) a loading request com- 
prising information about the software needed, 
and that the server 

sends the terminal the software needed, and 
that the terminal 

stores the software into its memory. 

6. A telephone system comprising 

a plural number of terminals (100, 102) and 
a server (128) monitoring and controlling the 
operation of the terminals, the server (128) be- 
ing arranged to calculate a check sum for soft- 
ware and for a certificate attached to the soft- 
ware; 

a terminal of the telephone system comprising 
means (204) for storing one or more software, 
and the system comprising 
one or more source computers (1 34) arranged 
to upload software to the server, the terminals 
(100, 102) being arranged to download soft- 
ware from the server, 

characterized in that 

the server is arranged to attach to the software 
a first check sum confirming the authenticity of 
the software before the software is downloaded 
to the terminals, and that 
a terminal is arranged to generate a second 
check sum from the downloaded software, after 
the software has been loaded, and that the ter- 
minal is arranged to check the authenticity of 
the software by comparing the first check sum 
with the second. 

7. A system according to claim 6, characterized in 
that the terminal is arranged to always check the 
authenticity of the software when the software is 
carried out. 

8. A system according to claim 6, characterized in 
that the server is arranged to generate an electronic 
signature by calculating for the software and the 
certificate a common check sum and to encrypt the 
calculated check sum by means of a secret key of 
the server. 

9. A system according to claim 6, characterized in 



that the terminal is arranged to decrypt the encryp- 
tion of the electronic signature by means of a public 
key of the server. 
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